home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pip-identifiers-02.txt
< prev
next >
Wrap
Text File
|
1993-06-18
|
11KB
|
344 lines
Network Working Group P. Francis
INTERNET-DRAFT (formerly P. Tsuchiya)
Bellcore
June 1993
Pip Identifiers
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
Pip is an internet protocol intended as the replacement for IP
version 4. The Pip header defines source and destination ID fields
whose primary function it is to identify the source and destination
of a Pip packet. While Pip systems treat the IDs as flat for the
purpose of identification, it is useful to have hierarchical
structure in the ID for other purposes, such as for doing a reverse
DNS lookup on the ID. This internet-draft defines the structure of
Pip IDs.
1. Changes From Previous Version
The previous version is dated January 1993. Following is a summary
of changes from that version.
Pip WG, Expires December 1, 1993 [Page 1]
INTERNET-DRAFT Pip Identifiers June 1993
1. A code point was added for "local" IP address. This is an IP
address that is not guaranteed to be globally unique. With this
code-point, a system can assign itself an ID based on its IP
address, but the ID will only be unique within the systems "IP-
unique" domain. As long as all IP addresses are unique, the ID
will also be unique.
2. A section describing Pip ID notation was added.
3. The ASN.1 style of assignment was removed. This results in the
Pip ID hierarchy not being self describing. This is the result
of a general notion that Pip IDs should largely be considered
flat entities, and in particular that Pip systems should use an
Ethernet number to derive their Pip IDs. Because the ASN.1
style of assignment was removed, all of the previous assignments
are different.
2. Introduction
Pip is an internet protocol intended as the replacement for IP ver-
sion 4. The Pip header defines source and destination ID fields
whose function, in the context of host processing of Pip headers, is
to only identify the source and destination of a Pip packet. While
Pip systems treat the IDs as flat for the purpose of identification,
it is useful to have hierarchical structure in the ID for other pur-
poses, such as for doing a reverse DNS lookup on the ID. This
internet-draft defines the structure of Pip IDs.
Pip IDs have the following characteristics:
1. With well-known exceptions, they are globally unique binary
strings 8 octets in length.
2. While they are hierarchically structured for assignment pur-
poses, the Pip layer does not treat them as hierarchical.
Further, assignments are set aside for such addresses as IEEE
802, resulting in what is effectively a flat ID.
3. Each component of the hierarchy is contiguous, and each
hierarchical component is positioned in the Pip ID adjacent to
its parent and child components.
Pip WG, Expires December 1, 1993 [Page 2]
INTERNET-DRAFT Pip Identifiers June 1993
4. Each level of the hierarchy can fall on an arbitrary bit boun-
dary.
5. Pip IDs may be used for group identification, but such a Pip ID
is not self-describing as being a group Pip ID.
6. Certain Pip IDs are well-known and have local meaning, such as
"all routers on the subnet" and "this host".
Pip IDs are formed by a hierarchy of number authorities, each of
which is responsible for assigning the next lower level of the
hierarchy. Generally it is the intent that Pip IDs be treated as
flat, and that the hierarchy is solely for the purposes of insuring
uniqueness. In particular, it is not assumed that an inverse DNS
lookup on the Pip ID works.
To the extent that the hierarchy in a Pip ID is exploited for other
purposes, it is recommended that the hierarchical structure of Pip
IDs follow administrative hierarchy (versus, for instance, topologi-
cal hierarchy). It is up to each number authority to determine how
the next level is assigned.
I should be noted that some people are of the opinion that Pip IDs
(or, network layer IDs in general) should have organizational
hierarchical content that might be used for accounting of various
kinds, inverse DNS lookups, and perhaps other things. Bob Smart and
John Curran in particular have put forth arguments to this effect,
and were acknowledged in the first draft of this document, which
embraced their philosophy. Since then, I have become concerned that
this placed too many constraints on Pip IDs, in particular with
regards to auto-configuration of hosts, and the need to change Pip
IDs when a host changes organizations. However, the issues of organ-
izationally meaningful Pip IDs versus flat Pip IDs is still an open
one. This specification does not prohibit the creation of organiza-
tionally meaningful Pip IDs, should that be found useful by various
organizations or across the board.
3. Pip ID Notation
This section describes a uniform method to write Pip IDs. This
method should be used whenever Pip IDs are written or typed. In par-
ticular, all software used to read or write Pip IDs should use this
notation.
Pip WG, Expires December 1, 1993 [Page 3]
INTERNET-DRAFT Pip Identifiers June 1993
A Pip ID is written as a sequence of 8 2-digit hex numbers separated
by dots. Leading 0's are written.
4. Assigned Top-level Pip ID Numbers
The top-level assignment authority (as yet unspecified, but IANA, the
Internet Assigned Numbers Authority, seems to be a logical candidate)
is responsible for assigning prefixes (the most significant bits) of
the Pip ID. By assigning a prefix, the top-level authority creates a
block of addresses, the authority of which is handed to another
organization.
The following Pip ID assignments are defined:
4.1. CCITT E.164
A CCITT E.164 address can be used to create a globally unique Pip ID.
Thus, anybody with an E.164 address can use it to form a globally
unique Pip ID. All Pip IDs formed from E.164 address have the form:
| 14-bit prefix |---50 bits---|
|00000000 000000| E164Address |
That is, 14 bits of value 0, followed by the E.164 address, converted
to binary (note this is not BCD encoding, but strict binary). 50
bits is adequate to encode all E.164 addresses in binary.
4.2. IEEE 802 Address
An IEEE 802 address can be used to create a globally unique Pip ID.
Thus, anybody with an IEEE 802 address can use it to form a globally
unique Pip ID. All IEEE 802 based Pip IDs have the format:
(hex) 80.00.IEEE802address
That is, the first 16 bits are (hex) 8000, followed by the 48 bit
IEEE 802 Address. Thus, the valid range of IEEE 802 based Pip IDs
is:
Pip WG, Expires December 1, 1993 [Page 4]
INTERNET-DRAFT Pip Identifiers June 1993
80.00.00.00.00.00.00.00 to 80.00.ff.ff.ff.ff.ff.ff.
4.2.1. Locally Unique ID
If a host has no IEEE 802 address, it can create a locally unique
(local to the subnet) Pip ID using the IEEE 802 prefix. To do this,
the local subnet address is placed in the low order part of the Pip
ID, and the remaining bits of the 48-bit space are filled in ran-
domly.
4.3. Local IP Domain
A Pip ID can be formed from an IP address. As long as IP addresses
are globally unique, a Pip ID formed from an IP address is also glo-
bally unique. All IP Address based Pip IDs have the format:
(hex) 40.00.00.00.IPaddress
That is, the first 32 bits are 40.00.00.00, followed by a 32-bit IP
Address. Thus, the valid range of IP based Pip IDs is:
40.00.00.00.00.00.00.00 to 40.00.00.00.ff.ff.ff.ff.
4.4. Flat Well-Known IDs
There are any number of uses for identifying systems of a certain
type, rather than specific systems. For instance, an ID for "all
routers on the LAN" is useful for router discovery. This specifica-
tion defines the following well-known Pip IDs. These well-known Pip
IDs consist of a single hierarchy level (the top-level), but are so
large that only one level of hierarchy is possible.
Any Router = ff.ff.ff.ff.ff.ff.ff.fe
Any Host = ff.ff.ff.ff.ff.ff.ff.fd
Any System = ff.ff.ff.ff.ff.ff.ff.fc
The above three well-known Pip IDs serve for functions such as "all
Pip WG, Expires December 1, 1993 [Page 5]
INTERNET-DRAFT Pip Identifiers June 1993
routers on a subnet", for instance in configuration algorithms such
as router discovery. Other well-known Pip IDs are expected to be
defined in the future.
4.5. Country Codes
While it is expected that most hosts will obtain their Pip ID from an
IEEE802 address (either from their interface card from from their
CPU), it may be necessary to obtains IDs from other sources. For
this purpose, a 32-bit block of IDs have been assigned to each coun-
try. The countries can further assign blocks to organizations if
desired. It should be noted that Pip systems with an assignment from
a country's block is in no way constrained to reside in that country.
Pip IDs formed by country code have a prefix of:
|------22 bit prefix-----|--10 bits---|----32 bits---|
|11000000 00000000 000000| ISO 3166 | remainder |
ISO 3166 is the ISO standard for country codes. All country codes
are between 0 and 999 (decimal), so 10 bits are adequate. The coun-
try codes are encoded in binary when in the Pip ID.
It is recognized that, in the long run, 32 bits per country will not
be adequate. When countries need more code space, it can be allo-
cated at that time. It is likely that we will have a better idea of
ID assignment needs at that time.
Pip WG, Expires December 1, 1993 [Page 6]